Skip to content

Configure more aggressive timeouts on non-ESTABLISHED TCP flow entries#985

Open
FelixMcFelix wants to merge 7 commits into
masterfrom
faster-syn-expiry
Open

Configure more aggressive timeouts on non-ESTABLISHED TCP flow entries#985
FelixMcFelix wants to merge 7 commits into
masterfrom
faster-syn-expiry

Conversation

@FelixMcFelix
Copy link
Copy Markdown
Collaborator

@FelixMcFelix FelixMcFelix commented May 7, 2026

This PR cuts down the TCP state entry expiry times for TCP flow entries which are either still within the three-way handshake or are actively being torn down. This does not affect the validity of any LFT entries which are responsible for actually procesing matched packets -- these exist on their own 60s expiry cadence.

This might have some impact on flow stat tracking for one or two packets, but the correct fix there is to get #744 over the line.

Should answer for
https://github.com/oxidecomputer/customer-support/issues/1125.

This PR cuts down the TCP state entry expiry times for TCP flow entries
which are either still within the three-way handshake or are actively
being torn down. This does not affect the validity of any LFT entries
which are responsible for actually *procesing* matched packets -- these
exist on their own 60s expiry cadence.

This might have some impact on flow state tracking, but the correct fix
there is to get #744 over the
line.

Should answer for
oxidecomputer/customer-support#1125.
@AlejandroME AlejandroME added this to the 19 milestone May 7, 2026
@FelixMcFelix FelixMcFelix marked this pull request as ready for review May 7, 2026 14:28
@twinfees twinfees added the customer For any bug reports or feature requests tied to customer requests label May 7, 2026
@rcgoodfellow
Copy link
Copy Markdown
Contributor

Added commits to bring this in line with #987. Testing in a4x2 and racklettes has been performed on this code. Note that this has a table size bump to 512k from 8k. This will result in 512k entries per-port in capacity on several tables that were previously limited to 8k.

@FelixMcFelix
Copy link
Copy Markdown
Collaborator Author

Thanks for all the testing and further tweaks. I can't self-approve what is technically my own PR, but I'm happy with the changes cherry-picked from #987. The table size bumps should have no impact on workloads with low flow counts -- BTreeMaps do not / cannot preallocate capacity.

From here on I'll be prioritising #986 and #779 with this as a base. The latter is more useful for making sure that lookups/insertions/deletions past around 1000 entries remain cheap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

customer For any bug reports or feature requests tied to customer requests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants